\documentclass[12pt,titlepage]{article}
\usepackage[spanish]{babel}
\usepackage[utf8]{inputenc}
\usepackage{amsfonts}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{color}
\usepackage{graphicx} % para insertar imagenes
\usepackage{verbatim}

\newcommand{\VSP}{\vspace*{3em}}
\newcommand{\Pa}{\vspace{5mm}}

\title{{\sc\normalsize Sistemas Operativos}\\{\bf Trabajo Práctico Nº1}}
\author{\begin{tabular}{lcr}
Carla Livorno & 424/08 & carlalivorno@hotmail.com\\Thomas Fischer & 489/08 & tfischer@dc.uba.ar
\end{tabular}}
\date{\VSP \normalsize{Agosto 2010}}
%\date{}
\begin{document}
\begin{titlepage}
\maketitle
\end{titlepage}
\tableofcontents
\newpage

\begin{section}{Ejercicio 1}

	El ejercicio consistió en implementar un cliente tipo \texttt{Telnet}
	con sockets UDP. El mismo es bastante simple ya que no hay ningún
	tipo de reconocimiento ni verificación entre el cliente y el servidor.

	Por lo tanto la implementación consistió en primer lugar en armar la dirección del
	servidor en la estructura de tipo \texttt{sockaddr\_in} requerida.

	Luego abrimos el descriptor de archivo del socket cliente con la
	función \texttt{socket} declarando su dominio como \texttt{AF\_INET} (internet) y el tipo como \texttt{UDP}.

	Una vez abierto el socket, simplemente enviamos a través del mismo
	mensajes (comandos) mediante la función \texttt{send} proporcionada a la
	dirección del servidor previamente establecida. Esto se repite hasta que el usuario ingresa el comando \texttt{chau} con el cual se cierra el socket.

	Un problema al programar con el protocolo UDP es que al mandar un
	mensaje no hay ningún tipo de feedback. Por lo tanto si el mensaje
	no llega al servidor, es muy dificil saber que falló, ya que el
	protocolo no nos garantiza que el mensaje llegue correctamente,
	y el cliente simplemente lo manda, llegue o no a un destino válido.

	La ventaja del protocolo frente a su alternativa mas importante (\texttt{TCP})
	es claramente su velocidad, ya que no hace ningun tipo de verificación al mandar y recibir datos.

\end{section}

\begin{section}{Ejercicio 2}
	En este ejercicio tuvimos que implementar tanto el cliente como el servidor tipo \texttt{Telnet} con protocolo \texttt{TCP}.
	Dado que se trata de una conexión \texttt{TCP} el cliente debe conectarse al servidor y esperar ser aceptado para poder enviar mensajes. Esto se debe a que a diferencia del protocolo \texttt{UDP} el servidor sabe quien le envia los mensajes.
	
	\begin{subsection}{Cliente}
		La implementación del cliente consistió en primer lugar,
		al igual que con \texttt{UDP}, en armar la dirección del servidor
		en la estructura de tipo \texttt{sockaddr\_in} requerida.

		Luego abrimos el descriptor de archivo del socket cliente
		con la función \texttt{socket} declarando su dominio
		como \texttt{AF\_INET} (internet) y el tipo como \texttt{TCP}.

		Una vez abierto el socket, debemos conectarlo al servidor.
		Si la conexión se realiza con exito el cliente puede comenzar
		a enviar los mensajes (comandos) mediante la función \texttt{send}.
		Una vez que envia el comando se queda a la espera del resultado.
		Recibe la respuesta a través de la función \texttt{read}
		que bloquea la aplicación hasta recibir una entrada
		y luego la almacena en un buffer.
		Este procedimiento se repite hasta que el usuario ingresa el comando \texttt{chau} con el cual se cierra el socket.
	\end{subsection}

	\begin{subsection}{Servidor}
	
		La implementación del servidor consistió en principio en crear
		el socket de domino \texttt{AF\_INET} (internet) y protocolo \texttt{TCP}.
		Luego definimos la direccion del servidor llenando una estructura
		de tipo \texttt{INADDR\_ANY}, con la cuál enlazamos al socket
		con un puerto del host mediante la función \texttt{bind}

		Una vez hecho esto, el servidor se queda escuchando si hay
		algún cliente que quiera establecer conexion
		mediante la función bloqueante \texttt{listen}.
		
		Ademas, se restringe a $uno$ la cantidad de clientes que pueden
		conectarse en simultaneo, a través de la misma función.
		Si algún cliente solicita la conexión al servidor, 
		\texttt{listen} se desbloquea y el servidor acepta al cliente
		mediante la función \texttt{accept}, estableciendo una conección
		a través de un socket particular para ese cliente.

		Cuando le llega un mensaje (un comando) al servidor, que recibe mediante
		la función \texttt{read}, el servidor hace uso de la función
		\texttt{popen} la cual crea un \texttt{pipe} con un nuevo shell
		donde ejecuta el comando pasado como parámetro,
		bloqueando la aplicación hasta terminar la ejecución.
		
		Luego leemos el resultado desde el pipe para enviarselo al
		cliente mediante la ya mencionada función \texttt{send}.
	
	\end{subsection}
\end{section}

\begin{section}{Observaciones}

	Cada vez que se envia o se recibe un mensaje limpiamos el buffer de mensajes recibidos
	con la función \texttt{memset}. Debemos limpiarlo para que
	no se mezclen los mensajes, es decir, de no limpiar el buffer por
	ejemplo si enviamos un mensaje de 8 caracteres seguido de uno de 5,
	los últimos 3 caracteres persisten en el mensaje.
	Otra solución es por ejemplo insertar un caracter nulo (\texttt{fin de string})
	al final del mensaje recibido, para delimitarlo.

	\textbf{Nota:} También modificamos el servidor del ejercicio $uno$
	para agregarle esta funcionalidad.
\end{section}

\end{document}
